1. Field of the Invention
The present invention relates generally to multimedia data such as audio and video, and more particularly to multimedia data allowing user customization and user access control.
2. Description of the Related Art
Due to the fact that networks have become speedier and client terminals have become highly sophisticated, the delivery of multimedia contents (e.g., audio, video) is now an important technological factor in a wide area network, e.g., the Internet. RTSP (IETF RFC2326), which is a control protocol of a multimedia stream, is one of these factors. RTSP is capable of the remote control, e.g., “PLAY”, “RECORD” and “STOP”, of a media stream which resides in a server by transmitting RTSP commands from a user to the server via a network.
FIG. 1 shows conventional art regarding the present invention. That is, a schematic diagram describing a controlling method of a media stream, which resides in a server using RTSP.
As shown in FIG. 1, a client terminal 100 which is to retrieve media, and a media server 101 which is to deliver the media, are interconnected via a network 103. The media server 101 is further connected to a media 102 where media is stored. The client terminal 100 remotely controls media stored in the media 102 through the media server 101 and the network 103. More specifically, the client terminal 100 transmits an RTSP request to the media server 101. The media server 101 prepares to control media stored in the media 102 as soon as the RTSP request is accepted and transmits an RTSP response to the client terminal 100.
FIG. 2 shows a sequence chart regarding the remote control of a media stream which resides in a server using RTSP. In FIG. 2, the client terminal 100 which is to retrieve media, and the media server 101 which is to deliver the media, are shown.
The client terminal 100 first transmits a “DESCRIBE” message to the media server 101, which means a request to retrieve the description of a media stream, in order to control media using RTSP. The media server 101 transmits the description of an appropriate media stream to the client terminal 100 according to the request. The client terminal 100 then transmits a “SETUP” message to the media server 101, which means a request to reserve resources. The media server 101 reserves resources and transmits a response message to the client terminal 100 according to the request. The client terminal 100, as soon as the response received, recognizes that the controlling of the media is now possible, and transmits “PLAY”, “RECORD” or “PAUSE” commands to the media server 101 in order to control the media. The media server 101 prepares to control the media according to the command and then transmits a response message for the command. Further, the media server 101 controls the media according to the received command. Finally, the client terminal 100 transmits a “TEARDOWN” message to the media server 101 so as to conclude the session.
There are “RANGE”, which specifies a timeframe of a media stream to be controlled, and “SCALE”, which specifies a viewing rate (speed), in an RTSP header. An appropriate scene can be retrieved using these commands. For instance, the client terminal 100 retrieves the start-time as well as the end-time of the requested scene from the media server 101 and then transmits a request containing the time range of the desired material in the “RANGE” header so that the client terminal 100 can retrieve the appropriate scene. Further, the client terminal 100 is capable of increasing the viewing rate using “SCALE” while viewing the media, and of returning to a normal viewing rate as soon as the appropriate scene has been viewed.
FIG. 3 shows an example of messages exchanged to view the media 102 which resides in the media server 101, using RTSP. It is to be noted that in FIG. 3, “C” stands for the client terminal 100, “S” stands for the media server 101, and for instance, “C→S” means a message transmitted from the client terminal 100 to the media server 101.
As shown in FIG. 3, a time range can be specified by adding a “RANGE” option in the URI of the media that is to be controlled by the client terminal 100. In FIG. 3, a sequence number of the message (CSeq) and a unique number of the session (Session) are described in order to clarify the uniqueness of a requested message. In the case shown in FIG. 3, the client terminal 100 requests to deliver the media starting from a 1,800-second scene. The media server 101 prepares to deliver the media starting from the 1,800-second scene according to the request, transmits an “OK” message to the client terminal 100 and then delivers the media using RTP. The client terminal 100 transmits RTCP for confirmation to the media server 101 as soon as it has received the media. Here, it is to be noted that the client terminal 100 has to know the time range for an appropriate scene in advance so as to request the appropriate scene from the media server 101.
In addition, an information delivery service which delivers various contents has become available in recent years. This information delivery service can provide a convenient service because it can be utilized as an advertising media, and a user can retrieve only appropriate information. In this regard, data describing the access privileges of a user is added to contents which are provided by a service provider, so as to control user access to the delivered information. In the conventional art, XAS (XML Access Sheet) which describes user the access privileges for a document structured by XML, i.e., XHTML, according to an XML format is made in a server, and the access privileges are determined by the service provider. In such an environment, it has been proposed that a document, according to the access privileges of a user, is automatically generated using XAS. Specifically, “Subject” specifying “to which user”, “Object” specifying “which information” and “Sign” specifying the access privileges to the “Object” are described in the XAS. In the “Subject”, not only a user account name, but also a source IP address, a group which the user belongs and its role can be described, which allows access control of the user from various points of view by assigning the user to “Subject”.
FIG. 4 shows a block diagram illustrating a method of generating a document from XHTML: the access privileges are reflected and the document is generated based on XAS. As shown in FIG. 4, there is an XHTML 1600 in which access control is to be applied, and a DTD 1601 which is a definition document of the XHTML 1600. Further, an XAS 1602 and an XAS 1603 are linked to the XHTML 1600 and DTD 1601, respectively. In order to apply access control to the XHTML 1600, the following processes are set: a parsing 1604 which parses the XHTML 1600 to a Document Object Model (DOM) tree; a labeling 1605 which labels each object of the DOM tree according to a “Sign” of XAS; a DOM transforming 1606 which transforms the DOM tree using only the elements labeled as “permit”, and an unparsing 1607 which unparses the DOM tree to XHTML. The parsing 1604 is first applied to the XHTML 1600 and it is parsed to a DOM tree. The labeling 1605 is then applied to the DOM tree so as to label each object based on the XAS 1602 and the XAS 1603. The DOM transforming 1606 is applied to the labeled DOM tree and it is transformed to a DOM tree configured by only the objects labeled as “permit”. The unparsing 1607 is then applied to the transformed DOM tree and unparsed to XHTML.
Further, the client terminal needs to refer to a DTD generated by objects, to which only the transformed XHTML refers, in order for a system to be transparent to the client terminal. A process of loosening 1608 is therefore set to match the DTD 1601 with the transformed XHTML. The loosening 1608 is applied to the DTD 1601 and it becomes a loose DTD. The method heretofore described, transformed XHTML 1609 and a loose DTD 1610, in which the access privileges of a user are reflected based on XAS, are automatically generated.
In the method of the conventional art described above, a requested scene can be retrieved by using the start-time and the end-time of the desired scene and by transmitting a request describing a time range in the “RANGE” header. Besides, the client terminal can increase the viewing rate using “SCALE” while viewing a media and can return to a normal viewing rate as soon as the appropriate scene is viewed.
However, in a communication network which allows a relatively longer delay, e.g., a mobile communication network, it takes a longer time at a client terminal from the transmission of an RTSP command, until the controlling of a delivered media becomes possible. It therefore takes a longer time to retrieve an appropriate scene using an RTSP command, and it is difficult to apply this method to the communication network at this point in time.
Moreover, it is expected that the access control method for XHTML will be applied to a dynamic content in terms of time, e.g., continuous media such as audio and video. In other words, the dynamic content has a large presentation description when compared with static content, e.g., a document and therefore, specifying a start-time is required to deliver the dynamic content. Since it is impossible to control each piece of information contained in the dynamic content, applying the access control method for XHTML to the dynamic content is not practical.